DevSecOps_08_LLM 기반 보안의 가능성과 통제 전략
보안 운영(SecOps)에서 가장 고통스러운 작업은 쏟아지는 경고(Alert)를 선별하는 트리아지(Triage)다. 최근 LLM(AI)이 이 영역의 구원투수로 등장했지만, 동시에 환각(Hallucination)이라는 치명적인 리스크도 안고 있다. AI를 "똑똑한 부조종사"로 활용하기 위한 가능성과 통제 전략을 알아본다.
1. 가능성: 문맥 이해와 오탐 제거
기존 룰 기반(Rule-based) 도구는 문맥을 모른다. 변수명이 password라는 이유만으로 단순 출력문(print)까지 경고를 띄운다. 하지만 LLM은 코드를 읽고 의도(Intent)를 파악한다.
- 이것이 사용자 입력을 받는 곳인가, 아니면 단순 로그 출력인가?
- 이 변수가 검증 함수를 거쳐서 사용되는가?
이러한 문맥 이해(Context Awareness) 능력 덕분에 LLM은 기존 도구의 고질적인 오탐(False Positive)을 획기적으로 줄이는 필터(Filter) 역할을 수행할 수 있다. 또한, "이 코드는 입력값 검증이 없어서 위험하다"와 같이 개발자 눈높이에 맞춘 상세한 설명과 수정 코드를 생성해준다.
2. 한계: 확률적 앵무새의 거짓말
그러나 LLM은 본질적으로 확률에 기반해 단어를 생성하는 기계다. 보안 영역에서 이는 심각한 부작용을 낳는다.
- 최신성 부족: 학습 데이터에 없는 최신 취약점(Zero-day)을 모른다.
- 비결정성: 같은 질문에 매번 다른 답을 내놓아 보안 진단의 일관성이 깨진다.
- 환각(Hallucination): 존재하지 않는 라이브러리를 안전한 패치라고 추천하거나, 취약한 코드를 안전하다고 오판한다.
3. 통제: 프롬프트 엔지니어링
따라서 AI를 보안 도구로 쓰려면 강력한 통제 장치가 필요하다. 이를 구현하는 핵심 기술이 프롬프트 엔지니어링이다.
3.1. RAG(Retrieval-Augmented Generation)
LLM의 "지식"을 믿지 말고, "독해력"만 빌려 써야 한다. 최신 CVE 데이터나 사내 보안 규정을 프롬프트에 참고자료(Context)로 넣어주고, "오직 위 문서를 근거로 답하라"고 제약한다. 근거가 없으면 "모른다"고 답하게 하여 거짓말을 원천 차단한다.
3.2. 역할 부여와 제약(Role & Constraints)
AI의 행동 범위를 좁혀야 한다. 창의성을 억제하고 논리적 수행만 강제한다.
- Role: "너는 리눅스 커널 보안 전문가다."
- Constraint: "기능 변경 없이 오직 보안 취약점만 패치하라."
- Format: "설명은 제외하고 코드 블록만 출력하라."
3.3. 생각의 사슬(CoT: Chain of Thought)
"안전한가?"라고 바로 묻지 말고, "단계별로 따져보라(Think step-by-step)"고 지시한다.
- 코드의 기능 파악 -> 2. 입력값 출처 확인 -> 3. 검증 로직 유무 확인 -> 4. 결론 도출.
이 과정을 강제하면 논리적 비약을 줄이고 훨씬 정확한 진단을 내릴 수 있다.
AI는 "최종 판단자"가 되어서는 안 된다. 1차 분석을 돕는 도구로 활용하되, 최종 방아쇠(Decision Making)는 반드시 사람이 당겨야 한다.